The testing of the designs of electronics devices such as, for example, network switches or other devices, is performed in order to verify the functionalities of the designs and to detect for possible defects. Functional verification of a design permits the testing of circuit behavior before implementation of the design. As known to those skilled in the art, test cases are used for testing of the design. A test case is implemented by software code and provides one or more sets of stimulus that is driven into a design-under-test (DUT) so that the design-under-test is tested for correct functionalities and possible defects.
In order to detect a bug during simulation and perform functional verification of a circuit design, vectors (i.e., test patterns) are applied to stimulate incorrect behavior by the DUT. Vectors are also applied to propagate and detect the incorrect behavior in the DUT. The user then traces back through the output waveforms from the DUT in order to attempt to locate the source that is causing the incorrect behavior.
If the HVL (Hardware Verification Language) testbench is not performing an intended function, then problems in debugging would occur. For example, if the signaling from the HVL testbench is wrong (e.g., due to timing errors), then problems in debugging would occur. For example, if two transactors (in an HVL testbench) are being used in the simulation and the signaling between the transactors is not correct, then problems in debugging may occur, and current systems make it difficult for the user to determine the cause of the error because the user can only observe the active threads and the DUT output. If the HVL testbench is implemented by the SPECMAN product or other HVL testbench products, the user will be unable to detect the erroneous signaling from the HVL testbench because the user is only able to view a list of all active threads via a browser, and the user is viewing the active threads only as text information. The user will have great difficulty in determining the erroneous signaling by observing the active threads after the treads executed one or more clock cycles. Therefore, previous approaches are unable to provide a view of testbench state at the post-simulation time period. Previous approaches are also unable to evaluate the effects of changes to the testbench other than by performing manually-controlled measurements during runtime. Previous approaches are also unable to compare testbench behavior and testbench state between two different simulation runs with two different sets of simulation settings.
Therefore, the current technology is limited in its capabilities and suffers from at least the above constraints and deficiencies.